To protect individuals from credit card and identity theft, the Payment Card Industry Data Security Standard (PCI DSS) mandates protection for all forms of stored credit card data. A common technique for satisfying portions of the PCI DSS requirements includes tokenizing account numbers (e.g., credit card account numbers, checking account numbers, debit account numbers, etc.). Conventional tokenization systems are configured to generate tokens based upon received account numbers, where a token for an account number is a randomized or pseudo-randomized sequence of characters that retains the formatting of the account number. Thus, the sequence of values 5645 6245 9878 4451 can be a valid token for account number 1111 2222 3333 4444, while “6fAlee%Z” would not be a valid token for the account number. Oftentimes, tokens are retained in a database for some length of time; for example, when a user has authorized a merchant to make a recurring charge to an account, the merchant may retain a token for the account in the database.
While tokens by themselves do not represent a security risk (since they are not strongly linked to the original credit card number, and cannot be used by themselves to make purchases), if a tokenization algorithm used to generate the tokens is compromised, such algorithm can be used to “invert” the tokens, and thus can be used to acquire the account numbers. Since a merchant must invert a token to acquire an account number (to obtain purchase approval from an issuer of the account), the merchant (or an agent of the merchant) typically stores the tokenization function in a readily-accessible location, such that the tokenization function can be retrieved relatively quickly when a token is to be inverted. This leads to a security risk, as a skilled hacker may acquire the tokenization function.